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VOLUME ENCRYPTION (layer selection) 

•HW 

• Application data 

• File system: (EncFS, eCryptfs, ...) 

• file level 

• metadata of algorithm in file, copy/move with data 

• parts of FS metadata unencrypted (attributes, file names, ...) 

• selection what is encrypted (which files, directories) 

• Block device: (dm-crypt, truecrypt, loop-aes, -.) 

• sector level encryption 

• independent of FS (layer below the FS) 

• mostly used with volume management (LVM) 

• swap partition 
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disc encryption 



" block device - atomic unit is sector 

• in Linux sector always 512 bytes, random access 

• sectors encrypted independently 

• (sectors contains random data before write) 

• encryption algorithm uses block <= sector 

• block is ususually 128bits (16 bytes) 

• last block has the same size as others 



key + IV 
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blockX 
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IV - initialization vector 

• different for every sector 

• derived from block number 

granularity - block vs sector 
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Block cipher algorithms (examples) 

aes-cbc-essiv:sha256, aes-xts-plain, ... 

■ Algorithm (define key length) 

AES, twofish, serpent, ... 

- Cipher block mode 

CBC (cipher block chaining) 

LRW (Liskov,Rivest,Wagner), since kernel 2.6.20 

XTS (XEX-TCB-CTS), since kernel 2.6.24, suitable for <1 TB data 

■ Wide modes (block=sector) need two pass processing, patented, mostly not used. 
(Maybe this change with prepared EME-2 which is not patent encumbered.) 

- IV - initialization vector 

• plain - sector number (padded with zeroes to requested size) 

• ESSIV - Encrypted Salt-Sector, derived from hash of key 
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Hidden volume 

- plausible deniability 

• ability to "plausible" deny that there are data 

• data stored in "unused" part of disc 

need another key, encrypted data looks like "random noise" 

• no visible header for encrypted data 

(you must decrypt the data and verify signature inside 
to prove that data are there) 









fake filesystem 
+ data 


hidden disc (inner encrypted disc) 
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• used in Truecrypt 

• with device-mapper you can create similar design 

• note possible "data leaks" to system from hidden disc 
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dm-crypt + cryptsetup 

■ kernel device-mapper crypt target 

used for transparent block device encryption 
(and use arbitrary filesystem above that) 

■ Using kernel cryptoAPI 

• HW support (VIA Padlocl<, Geode, AES-NI, ...) 

■ cryptsetup[-luks] - tool for dm-crypt configuration 

* defines LUKS key store 

■ + GUI, udev, HAL integration 
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LUKS (Linux Unified Key Setup) 



de facto standard in Linux 



portable, supported by other OS (FreeOTFE.org) 
several passphrases unlocks strong volume key, PBKDF2 
passphrase change (invalidation) 
• without whole disc reencryption 



LUKS DISK 



LUKS hdr 


key material 


params 


slot 1 





master key calc. ^ 



AF-splltter - anti-forensic protection 
(against master key revive from hw reallocated sectors) 
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cryptsetup 

LUKS commands: Format, Open, Close, AddKey, KillSlot, Dump 

(create, remove, status - direct dm-crypt setting without LUKS) 

luksFormat - create LUKS header 

cryptsetup [-c serpent-cbc-essiv: sha256 -s 256] luksFormat $DEV 

luksOpen - make device available (map device) 

cryptsetup luksOpen $DEV $CRYPT_DEV_NAME 

luksClose - remove mapping 

cryptsetup luksClose $CRYPT_DEV_NAME 

luksAddKey, luksKillSlot, (luksRemoveKey) - keyslots manipulation 
luksDump - show info about encrypted disc 

Cipher name: serpent 

Cipher mode: cbc-essiv: sha256 

Payload offset: 2056 

UUID: 0 97 14b0c-9a7 0-4 652-8 6d2-73 0 0b7 55eb4f 
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cryptsetup 

Configuration example - distro dependent 
/etc/crypttab: 

#<tgt.dev> <src.dev> <key file> <options> 

- simple disc, LUKS (no paramaters needed) 

$CDISK /dev/sdX none retry=5 

- swap over LVM volume, no LUKS, random volume key (differs every boot) 

- note that init scripts must initializei RNG during bootu before - random seed 

$CSWAP /dev/VG/lv /dev/urandom swap, cipher=aes-cbc-essiv : sha25 6 

/etc/fstab: 

/dev/mapper/$CDISK $MNT auto defaults 0 0 

/dev/mapper / $CSWAP swap swap defaults 0 0 
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cryptsetup 

Resize of encrypted disc 

• No device size in LUKS header, 

just resize underlying device and activate 

• ... and change FS size above 

• ... and fill new space with random data 

Change of encryption algorithm, volume key, ... 

• The safest way: use copy to another disc 



In future integration into LVM and to key management system 
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Cryptsetup + LVM (Logical Volume Management) 



LVM metadata - redundance, history of changes 
LUKS metadata - undesirable to keep old header 

LVM over encrypted disc 

• PV is encrypted disc 

• LVM metadata are encrypted too 
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LVM 



/dev/vg/lvl 
/dev/vg/lv2 
/dev/vg/lv3 



/ de v/mappe r / c r ypt" 
1 



crypsetup luksOpen \ 
/dev/sdX crypt 

vgscan 

vgchange -a y vg 
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Cryptsetup + LVM (Logical Volume Management) 
■ encrypted LVM volume 

• only some volumes can be encrypted 
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/dev/vg/lv2 




/ de v/mappe r / c r ypt 



vgchange -a y vg 



cryptsetup luksOpen \ 
/dev/vg/lv2 crypt 



• both usable for system disc 

• ... but you have to use initrd 

• ... with all requested kernel modules (disc, dm-crypt, crypto) 
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Backup, recovery 

■ No LUKS header - all data gone 

■ Error diffusion 

• one bad bit in RAIVi - loss of one block of encrypted data (at least) 

• HW errors usually leads to worse situation then with plain disc 

■ Data recovery 

• Backup data inside the encrypted device :-) 

• LUKS 

• Backup of mapping table and volume key 

• dmsetup table — showkeys 

• If you know volume key and algorithm, no need for passphrase 

• LUKS header backup 

• dd if =/dev/<dev> of =backup . img bs=512 count=NUM 

• NUM - sector count in Payload Offset (luksDump) 

• You need to know (one) passphrase 
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dm-crypt performance 

■ encryption speed... 

• CPU load, 10 pattern type, various optimalisation 

• lOs are serialized (processed in sequence) 
• a file sync can wait for other data 

• Special encryption thread per volume, latency 

• multicore/SMP support? 

• HW acceleration 

• formerly used in IPsec 

• transparent, kernel drivers 

• asynchronnous mode 



